IT Semester VI SPM Software effort estimation techniques
Software effort estimation techniques:
Barry Boehm, in his classic work on software effort models, identified the main ways of deriving estimates of software development effort as:
-
algorithmic models - which use 'effort drivers’ representing characteristics of the larger system and the implementation environment to predict effort;
-
expert judgement - where the advice of knowledgeable staff is solicited;
-
analogy - where a similar, completed, project is identified and its actual effort is used as a basis for the new project;
-
Parkinson - which identifies the staff effort available to do a project and uses that as the 'estimate’;
-
price to win - where the ‘estimate" is a figure that appears to be sufficiently low to win a contract;
-
top-down - where an overall estimate is formulated for the whole project and is then broken down into the effort required for component tasks;
-
bottom-up - where component tasks are identified and sized and these individual estimates are aggregated.
Clearly, the ’Parkinson' method is not really an effort prediction method, but a method of setting the scope of a project. Similarly, ‘price to win' is a way of deciding a price and not a prediction method- On these grounds, Boehm rejects them as prediction techniques although they might have some value as management techniques. There is, for example, a perfectly acceptable engineering practice of ‘design to cost' which is one example of the broader approach of ’design by objectives'.
Bottom-up estimating
Estimating methods can he generally divided into bottom-up and top-down approaches. With the bottom up approach, the estimator breaks the project into its component tasks and then estimates how much effort will be required to earn out each task. With a large project, the process of breaking down into tasks would be a repetitive one: each task would be analysed into its component sub-tasks and these in turn would he further analysed. This is repeated until you get to components that can he executed by a single person in about a week or two. The reader might wonder w hy this is not called a top-down approach: after all you are starting from the top and working down! Although this top-down analysis is an essential precursor to bottom-up esiimating, it is really a separate one - lhal of producing a Work Breakdown Structure (WBS).
Expert judgement
This is asking someone w ho is knowledgeable about either the application area or the development environment to give an estimate of the effort needed to carry out a task. This method will most likely he used when estimating the effort needed to change an existing piece of software. Thus estimator would have to carry out some kind of impact analysis in order to judge the proportion of code that would be affected and from that derive an estimate. Someone already familiar with the software would be in the best position to do this.
5.7 Estimating by analogy
The use of analogy is also called case-based reasoning. The estimator seeks out projects that have been completed (source raws) and that have similar characteristic to the new project (the target cose). The effort that has been recorded for the matching source case can then be used as a base estimate for the target. The estimator should then try to identify any differences between the target and the source and make adjustments to the base estimate for the new project. This might be a good approach where you have information about some previous projects hut not enough lo draw generalised conclusions about what variables might make good size parameters. A problem here is how you actually identify the similarities and differences between the different systems. Attempts have been made to automate this process. One software application that has been developed to do this is ANGEL, This identities the source case that is nearest the target by measuring the Euclidean distance between eases, lire source case that is at the shortest Euclidean distance from the target is deemed to be the closest match. The Euclidean distance is calculated:
distance = square-root of {(target parameter1 - source parameter1)2+ .... + (Target parametern— source_parametern)2